A heterogeneous network media independent handover (MIH) technology according to a related art is explained as follows. An object of IEEE 802.21 is for the international standardization of inter-heterogeneous-network media independent handover. Inter-heterogeneous-network media independent handover aims to enhance a user's convenience when using mobile terminal devices by providing seamless handover and service continuity between heterogeneous networks. An MIH function, an event trigger and an information service (IS) are defined as basic requirements for the technology.
A mobile terminal is a multi-node that supports at least one interface type. For example, various interface types supported are a wire-line interface type, such as an IEEE 802.3-based Ethernet, a wireless interface type, such as an IEEE 802.11, IEEE 802.15 and IEEE 802.16 interface, and an interface defined by a cellular standardization organization, such as 3GPP and 3GPP2.
FIG. 1 is an exemplary diagram of a mobile terminal supporting a media independent handover (MIH) function. Referring to FIG. 1, a mobile terminal supporting a media independent handover function can have the media independent handover function provided within a protocol structure to enhance performance while performing handover. For example, a service delay, user's sensory index, and the like may be improved. A possible configuration of the MIH function is shown in FIG. 1. The MIH function is not a protocol layer, but a function. A link layer and interface exist below the MIH function. All upper layers and interfaces exist above the MIH function.
Media independent handover (MIH) is defined between IEEE 802-series interfaces, or between an IEEE 802-series interface and a non-IEEE 802-series interface, such as a 3GPP or 3GPP2 interface. A mobility supporting protocol of an upper layer such as a Mobile IP and a session initiation protocol (SIP) is supported for seamless handover service.
A transmission control protocol (TCP) loss recovery mechanism is explained as follows. The TCP loss recovery mechanism attempts to recover a packet loss through retransmission when detecting the packet loss. The TCP loss recovery mechanism includes two elements: 1) Fast Retransmit; and 2) Fast Recovery.
A related art is explained as follows.
Heterogeneous Network Handover
MIH (Media Independent Handover)
An MIH function is placed below an IP layer and facilitates a handover handling process using an input value from Layer 2 such as a trigger event, information for another network and the like. The MIH function can include input values based on user policy and configuration that may affect a handover process.
General interfaces are defined between the MIH function and a Layer 3 entity, such as the Mobile IP and SIP. These interfaces provide information for Layer 1 (physical layer), Layer 2 (medium access control layer) and mobility management. The MIH function also acquires information for lower layers and a network with the help of an event service and an information service. Hence, the MIH function is placed for an upper layer to monitor and control a status of another link within a mobile terminal.
FIG. 2 is a block diagram of functional entities and a transport protocol of a user equipment (UE) or mobile terminal and a network using MIH function technology. Dotted lines indicate primitives, event triggers and the like.
Event Service
For fast handover, a network layer needs to use information from a link layer to reconfigure a connection as soon as possible. A link layer event is helpful for estimating a user's movement and can help a mobile terminal and a network prepare handover in advance.
A trigger for handover can start from a physical layer (PHY) or a medium access control layer (MAC). An origin of this trigger can be a local stack or a remote stack. An event service is classified into an MIH event and a link event. An event within the local stack is a local event. An event service transferred to the remote stack is a remote event.
FIG. 3 is a block diagram of a local event model and an MIH event model. Referring to FIG. 3, an MIH event is an event delivered from the MIH function to an upper management entity or an upper layer and corresponds to an event trigger according to a related art. A link event is an event delivered to the MIH function from a lower layer (MAC or physical layer) and uses primitives used in each interface MAC or physical layer.
FIG. 4 is a block diagram of a remote link event model. Referring to FIG. 4, if an event is triggered from a lower layer within a local stack to an MIH function within the same local stack, the MIH function of the local stack delivers the event to an MIH function of a remote stack. Accordingly, this triggers an event to a remote stack MIH function from a lower layer within the remote stack. From this, a trigger is delivered to the MIH function of the local stack as well.
FIG. 5 is a block diagram of a remote MIH event model. Referring to FIG. 5, an MIH function within a local stack triggers a remote MIH event and then transfers the event to a correspondent MIH function within a remote stack. The correspondent MIH function delivers the event to an upper management entity or an upper layer within its stack. Accordingly, this triggers an event to the local stack MIH function from the MIH function within the remote stack. From this, a trigger is delivered to an upper layer within the local stack as well.
FIG. 6 is a block diagram of an MIH command model and a link command model. Referring to FIG. 6, an MIH command is generated from an upper management entity or an upper layer to be delivered to an MIH function. The MIH command instructs the MIH function to perform a prescribed action. A link command is generated from an MIH function and delivered to a lower layer. The link command instructs the lower layer to perform a prescribed action.
FIG. 7 is a block diagram of a remote MIH command model. Referring to FIG. 7, a remote MIH command is generated from an upper management entity or an upper layer within a local stack and is delivered to an MIH function. The MIH function of the local stack then delivers the command to a correspondent MIH function within a remote stack. Accordingly, this triggers a command to a remote stack MIH function from an upper layer within the remote stack. From this, the command is delivered to the MIH function within the local stack as well.
FIG. 8 is a block diagram of a remote link command model. Referring to FIG. 8, an MIH function within a local stack generates a remote link command and delivers the command to a correspondent MIH function within a remote stack. The correspondent MIH function then delivers the command to a lower layer within the remote stack. Accordingly, this triggers a command to the local stack MIH function from the MIH function within the remote stack. From this, the command is delivered to a lower layer within the local stack as well.
An event trigger provides information related to a status change of a network different from a status of a current signal. The event trigger may also provide information related to an estimated change of the network. Furthermore, the event trigger includes changes on physical and medium access control layers and attribute changes of a specific network.
Event types can be classified as follows: 1) PHY layer event; 2) MAC layer event; 3) Management event; 4) L3 event; and 5) Application event.
A basic trigger event is explained as follows. A Link_Up occurs when a Layer 2 (L2) connection is established on a specific link interface and when Layer 3 (L3) packets can be transferred from a higher layer. In this case, it is decided that all L2 configurations configuring the link are completed. An event origin of the Link_Up is a local MAC and a remote MAC. Parameters of the Link_Up are shown in Table 1.
TABLE 1NameTypeDescriptionEventSourceEVENT_LAYER_TYPEOrigin from which event is generatedEventDestinationEVENT_LAYER_TYPEDestination to which event shall be deliveredMacMobileTerminalMAC AddressMAC address of MSSMacOldAccessRouterMAC AddressMAC address of old access routerMacNewAccessRouterMAC AddressMAC address of new access routerNetworkIdentifierMedia SpecificNetwork Identifier usable in detecting change ofsubnet
A Link_Down occurs when an L2 connection is released on a specific interface and when it is no longer able to transfer L3 packets. An event origin of the Link_Down is a MAC. Parameters of the Link_Down are shown in Table 2.
TABLE 2NameTypeDescriptionEventSourceEVENT_LAYER_TYPEOrigin from which event is generatedEventDestinationEVENT_LAYER_TYPEDestination to which event shall be deliveredMacMobileTerminalMAC AddressMAC address of MSSMacOldAccessRouterMAC AddressMAC address of old access routerReasonCodeReason why link is released
A Link_Going_Down occurs when it is estimated that an L2 connection is going to link down within a specific time. Also, the Link_Going_Down may be a signal for initializing a handover procedure. An event origin of the Link_Going_Down is a local MAC and a remote MAC. Parameters of the Link_Going_Down are shown in Table 3.
TABLE 3NameTypeDescriptionEventSourceEVENT_LAYER_TYPEOrigin from which event is generatedEventDestinationEVENT_LAYER_TYPEDestination to which event shall be deliveredMacMobileTerminalMAC AddressMAC address of MSSMacOldAccessRouterMAC AddressMAC address of old access routerMacNewAccessRouterMAC AddressMAC address of new access routerTimeIntervalTime in msecsEstimated time for Link_DownConfidenceLevel%Estimated level for Link_Down of link in a specifictimeUniqueEventIdentifierUsed in case that Event rollback occurs
A Link_Going_Up occurs when it is estimated that an L2 connection is going to link up within a specific time. Also, the Link_Going_Up is used when a long time is taken for a network to be initialized. An event origin of the Link_Going_Up is a local MAC and a remote MAC. Parameters of the Link_Going_Up are shown in Table 4.
TABLE 4NameTypeDescriptionEventSourceEVENT_LAYER_TYPEOrigin from which event is generatedEventDestinationEVENT_LAYER_TYPEDestination to which event shall be deliveredMacMobileTerminalMAC AddressMAC address of MSSMacOldAccessRouterMAC AddressMAC address of old access routerMacNewAccessRouterMAC AddressMAC address of new access routerTimeIntervalTime in msecsEstimated time for Link_UpConfidenceLevel%Estimated level for Link_Up of link in a specific timeUniqueEventIdentifierUsed in case that Event rollback occurs
A Link_Available indicates that a new specific link is usable or available. The Link_Available indicates a possibility that a new base station or point of attachment (POA) can provide a link having a better quality than that of a base station or point of attachment currently accessed by a mobile terminal. An event origin of the Link_Available is a local MAC and a remote MAC. Parameters of the Link_Available are shown in Table 5.
TABLE 5NameTypeDescriptionEventSourceEVENT_LAYER_TYPEOrigin from which event is generatedEventDestinationEVENT_LAYER_TYPEDestination to which event shall be deliveredMacMobileTerminalMAC AddressMAC address of MSSMacOldAccessRouterMAC AddressMAC address of old access routerMacNewAccessRouterMAC AddressMAC address of new access router
An MIH protocol includes the following steps: 1) MIH Capability Discovery; 2) MIH Registration; and 3) MIH Message Exchange. During MIH Capability Discovery, an MIH of a mobile terminal or an MIH of a base station/access router discovers what type of entity on a network supports an MIH function. During MIH Registration, MIH functions of different entities execute registration procedures with each other to initiate the MIH protocol, respectively. During MIH Message Exchange, after completion of the registration procedures, two MIH functions can transmit/receive MIH messages using MIH payloads and the MIH protocol.
FIG. 9 is a block diagram of a relationship between an MIH function (MIHF) and another protocol layer within a stack. Referring to FIG. 9, when transmitting an MIH message to a remote MIHF from an MIHF within the stack, the MIH message can be transmitted using a link layer. The MIHF message can also be transmitted as an IP packet using an IP layer.
MIH Packet Format
FIG. 10 is a diagram of an MIH packet message format. Referring, to FIG. 10, an MIH Message Type (1-octet) is classified according to Table 6.
TABLE 6MIH Message TypeMIH Message NameMIH Message Type 1MIH_Capability_Discover.requestCapability Discovery 2MIH_Capability_Discover.responseCapability Discovery 3MIH_Capability_Discover.advertisementCapability Discovery 4MIH_Registration.requestRegistration 5MIH_Registration.responseRegistration 6MIH_Deregistration.requestRegistration 7MIH_Deregistration.confirmRegistration 8MIH_Event_Register.requestRegistration 9MIH_Event_Register.confirmRegistration10MIH_Event_Deregister.requestRegistration11MIH_Event_Deregister.confirmRegistration12MIH_Link_Up.indicationEvent Service13MIH_Link_Down.indicationEvent Service14MIH_Link_Going_Down.indicationEvent Service15MIH_Link_Event_Rollback.indicationEvent Service16MIH_Link_Parameters_Change.indicationEvent Service17MIH_Link_Event_Discover.requestCommand Service18MIH_Link_Event_Discover.confirmCommand Service19MIH_Network_Address_Information.requestCommand Service20MIH_Network_Address_Information.responseCommand Service21MIH_Handover_Pre-notification.requestCommand Service22MIH_Handover_Pre-notification.responseCommand Service......  23+ReservedReserved
Still referring to FIG. 10, Length (1-octet) indicates a total length of an overall header including an MIH message. Sequence Number (1-octet) is a total count of message transmissions. IP (1-bit) indicates whether an IP address included in a header is of an IPv4 or IPv6 protocol (e.g., 0: IPv4, 1: IPv6). F (1-bit) indicates whether a message is fragmented or not (e.g., 0: No Fragmentation, 1: Fragmentation).
With regard to Fragmentation Offset (1-octet), fragmentation indicates how many packets are left to configure a complete message in case that a message is incomplete with one packet. XID (Packet ID) (1-octet) is used in matching each request message and confirm message. Source Hardware Type (4-bit) indicates a hardware type of a party that transmits a corresponding message (e.g., 0000: IEEE 802.3 interface, 0001: IEEE 802.11 interface, 0010: IEEE 802.16 interface, 0011: 3GPP interface, 0100: 3GPP2 interface, 0101˜11111: Reserved). Destination Hardware Type (4-bit) indicates a hardware type of a party that receives a corresponding message (e.g., 0000: IEEE 802.3 interface, 0001: IEEE 802.11 interface, 0010: IEEE 802.16 interface, 0011: 3GPP interface, 0100: 3GPP2 interface, 0101˜11111: Reserved).
Source Hardware Address indicating a hardware address of a party that transmits a corresponding message (e.g., Layer 2 address). Destination Hardware Address indicates a hardware address of a party that receives a corresponding message (e.g., Layer 2 address). Destination IP Address indicates an IP address of a party that receives a corresponding message. MIH Message is a field where a substantial message of a remote event registration, event service and command service is included in a TLV (type, length and value) format.
Inter-MIH Signaling Message
An inter-MIH signaling message can be classified into: 1) MIH Capability Discovery; 2) Remote MIH Event Registration; and 3) Remote MIH Event Service and Remote MIH Command Service.
(1) MIH Capability Discovery Associated Message
An MIH_Capability_Discovery.request message does not include an MIH message payload, but is transmitted in a manner of setting a message type to 1 with an MIH header only. This message can be delivered via Layer 2 or 3. If an entity transmitting this message does not know an exact address of a correspondent entity and attempts to discover an entity having an MIH function within a network, this message is transmitted as a broadcast message. If an entity transmitting this message knows an address of a correspondent entity and attempts to know a presence or non-presence of an MIH function of the correspondent entity, this message transmitted as a unicast message.
An entity having received the MIH_Capability_Discovery.request message responds with an MIH_Capability_Discovery.response message if the entity has an MIH function. This message does not include an MIH message payload but is transmitted in a manner of setting a message type to 1 with an MIH header only. This message can be delivered via Layer 2 or 3. In this case, a destination address field is filled in the MIH header by copying a source address of the MIH_Capability_Discovery.request message. A source address field is filled in the MIH header with the entity's address. Moreover, an entity having an MIH function can periodically advertise its MIH function via Layer 2 or 3.
(2) MIH Registration Associated Message
An MIH_Event_Registration.request message is used by an MIH function attempting to register a specific event service to be delivered to a remote stack.
TABLE 7Type (1Namebyte)LengthValueRequestedEventList1If an area of each bit is set to 1,it means that a request ismade to have a correspondingservice registered.Bit #0: Link UpBit #1: Link DownBit #2: Link Going DownBit #3: Link DetectedBit #4: Link Parameters ChangeBit #5: Link Event Rollback6~7: Reserved
An MIH_Event_Registration.confirm message returns a result of a registration request.
TABLE 8Type (1Namebyte)LengthValueResponseEventList1If an area of each bit isset to 1, it means that acorresponding serviceis successfully registered.Bit #0: Link UpBit #1: Link DownBit #2: Link Going DownBit #3: Link DetectedBit #4: Link Parameters ChangeBit #5: Link Event Rollback6~7: Reserved
An MIH_Event_Deregistration.request message is delivered to deregister an event service having been registered to a remote stack.
TABLE 9Type (1Namebyte)LengthValueRequestedEventList1If an area of each bit is set to 1,it means that a request is madeto have a correspondingservice deregistered.Bit #0: Link UpBit #1: Link DownBit #2: Link Going DownBit #3: Link DetectedBit #4: Link Parameters ChangeBit #5: Link Event Rollback6~7: Reserved
An MIH_Event_Deregistration.confirm message returns a result of the MIH_Event_Deregistration.request.
TABLE 10Type (1Namebyte)LengthValueResponseEventList1If an area of each bit is set to 1,it means that acorresponding service issuccessfully deregistered.Bit #0: Link UpBit #1: Link DownBit #2: Link Going DownBit #3: Link DetectedBit #4: Link Parameters ChangeBit #5: Link Event Rollback6~7: Reserved
(3) MIH Event Service Associated Message
An MIH_Link_Up.indication message is used by a mobile terminal or a point of attachment to transmit a Link_Up message to a remote stack. The MIH_Link_Up.indication message informs the remote stack that a new link connection is configured. Moreover, this message can be delivered to all entities supporting an MIH function from all entities supporting an MIH function as well as the mobile terminal or the point of attachment.
TABLE 11TypeName(1 byte)LengthValueMacMobileTerminalVariableMAC AddressMacNewPoAVariableMAC Address of New PoA(AP)MacOldAccessRouterVariableMAC Address of oldAccess Router (if any)MacNewAccessRouterVariableMAC Address of newAccess Router
An MIH_Link_Down.indication message is used by a mobile terminal or a point of attachment to transmit a Link_Down message to a remote stack. The MIH_Link_Down.indication message informs the remote stack that a new link connection is released. Moreover, this message can be delivered to all entities supporting an MIH function from all entities supporting an MIH function as well as the mobile terminal or the point of attachment.
TABLE 12Type (1Namebyte)LengthValueMacMobileTerminalVariableMAC AddressMacNewPoAVariableMAC Address of New PoA (AP)MacOldAccessRouterVariableMAC Address of old Access Router (if any)ReasonCode1The reason why a link connection is released is informed.0: Release of a link connection by a defined procedure(RC_EXPLICIT_DISCONNECT)1: Release of a link connection by a timeout of packet(RC_PACKET_TIMEOUT)2: Release of a link connection by a communication resource(RC_FAIL_NORESOURCE)3~127: Reserved128~255: RC_VENDOR_SPECIFIC
The ReasonCode field of Table 12 is explained as follows.
An RC_EXPLICIT_DISCONNECT value indicates that a link connection is released by a link connection release procedure generated by a client or network. An RC_PACKET_TIMEOUT value indicates that a link connection is released because and acknowledgment (ACK) for a transmitted packet is not received within a predetermined time. An RC_FAIL_NORESOURCE value indicates that a link connection is released because there is no resource to maintain the connection. An RC_VENDOR_SPECIFIC value explains why a link connection has been released upon determination by a communication provider.
FIG. 11 is a flowchart of a procedure for discovering whether a correspondent node of communication supports an MIH function (MIHF) through an Internet Protocol (IP), in case of Layer 3, for example. Referring to FIG. 11, a mobile terminal transmits an MIH_Capability_Discover.request message to an IP address discovered while configuring a communication connection with a correspondent node [S1110]. Furthermore, the mobile terminal drives a timer during the transmission of the message [S1120]. The correspondent node, which supports the MIHF, can receive the message and then transmits an MIH_Capability_Discover.response message in response to the received message [S1130]. Because a response message arrives before the expiration of the timer, the mobile terminal can discover that the correspondent node supports the MIHF.
Congestion Control Mechanism of TCP
1. Fast Retransmit
A loss recovery process of every transmission control protocol (TCP) starts from Fast Retransmit. Prior to explaining an operation of Fast Retransmit, it is necessary to understand Duplicate Acknowledgement. Referring to FIG. 12, it is assumed that packets 1 to 4 are transmitted while a size of a window is four. Furthermore, the packet 2 is lost during transmission.
The TCP informs a transmitting source (Host A) of a last packet so far received among packets normally received each time a packet is received. This operation is called Cumulative Acknowledgement. Accordingly, a receiving source (Host B) having received the packet 1 transmits an acknowledgement packet to the transmitting source (Host A) indicating that it is ready to receive the packet 2, i.e., that packets including the packet 1 were normally received.
Because the packet 2 is lost in the course of transmission, the receiving source receives the packet 3 while not receiving the packet 2. Thus, the receiving source having received the packet 3 delivers the same acknowledgement packet indicating that the received last packet is the packet 1 and that it is ready to receive the packet 2 again. This scenario is called Duplicate Acknowledgement.
In case of receiving three Duplicate Acknowledgements, the transmitting source concludes that the corresponding packet was lost and retransmits the lost packet immediately, which is a basic operation of a Fast Retransmit Algorithm. In case of not using Fast Retransmit, the transmission is always re-initiated after expiration of a retransmission timeout if a packet loss takes place. Hence, Fast Retransmit considerably enhances the performance of the TCP.
FIG. 13 is a graph of a size variation of a window according to Fast Retransmit. Referring to FIG. 13, a lost packet is generated when a size of a window is W(loss). After the lost packet is retransmitted according to Fast Retransmit, a value of a slow start threshold (ssthresh) is set to W(loss)/2, wherein there is no special theoretical background for reducing the value to a half.
Assuming that w packets are transmitted if a size of a window of a transmitting source in slow start mode is w, a size of a window in case of receiving w acknowledgement packets becomes 2w, and 2w packets are transmitted. If a packet loss takes place at this point in time, the corresponding packet is retransmitted by Fast Retransmit and the value of ssthresh is reduced to w, which is half of a current window size. Accordingly, an approximate maximum size of the window having no packet loss is w. Hence, in subsequent transmissions, the window is set to be increased by Slow Start until this value.
Moreover, according to the related art, Additive Increase Multiplicative Decrease of a window used in a congestion control protocol based on another window as well as TCP shows the best performance in providing fairness in case that there exist many transmitting sources.
As shown in FIG. 13, after the corresponding packet is successfully retransmitted, the size of the window is set to 1 again. Also, the window size increases to the half-reduced ssthresh in slow start mode. In case that it is impossible to recover the lost packet by Fast Retransmit, slow start begins after the expiration of a retransmission timeout. In this case, the value of ssthresh corresponds to a half of the window prior to the occurrence of the packet loss.
2. Fast Recovery
The appearance of a Fast Recovery Algorithm is closely associated with an abrupt increase of a data rate of a network. In general, a connection between a transmitting source and a receiving source is called a pipe. The product of a round trip time (RTT) and an approximate data rate is called a Bandwidth-Delay-Product (BDP). A connection on a network having a considerable data rate and transfer delay such as a satellite network is expressed as a Long-Fat Pipe. Thus, when a BDP is considerably large, it is highly probable that a window will increase correspondingly. Accordingly, the number of outstanding packets, which are currently transmitted and not yet acknowledged, corresponds to a large value as well. Fast Recovery is explained with reference to FIG. 14 as follows.
FIG. 14 is a diagram of a process for performing Fast Retransmit when a packet (packet 1) is lost while a transmitting source and a receiving source are connected together by a pipe having a Neighbor Discovery Protocol (NDP) equal to a size of 16 packets. Referring to FIG. 14, three duplicate acknowledgements for packet 1 are delivered. A transmitting source having received the duplicate acknowledgements retransmits them by Fast Retransmit. In this case, 12 packets corresponding to 75% of a total capacity still remain in the pipe. Namely, since information for the current pipe can be sufficiently obtained from the remaining 12 packets, i.e., since a clocked-state can be maintained, or since probing is possible, it is unnecessary to initiate Slow Start again after Fast Retransmit.
Therefore, if the lost packet is successfully retransmitted by Fast Retransmit, subsequent transmissions are continually performed with a window set to a value of ssthresh in Congestion Avoidance mode. For Fast Recovery, the transmitting source increments a size of the window by 1 each time a duplicate acknowledgement packet is received. If a packet, which is not yet transmitted, is included in the window, the corresponding packet is transmitted. By these packets, it is possible to maintain a synchronized state of the pipe.
According to a previous design of the TCP congestion control, packet transmission is mainly performed on a reliable wire link, i.e., on a link having a low possibility of losing a packet due to transmission error. Thus, the TCP congestion control mechanism is designed to interpret all packet losses as congestion occurrences in a network and considerably reduce a corresponding size of a window or stop a retransmission timeout (RTO) packet transmission for a period of time. However, when the TCP operates on a radio link, a bit error rate (BER) of a radio link is originally higher than that of a wired network. Bit errors can have continuity due to Multi-Path Fading and a connection is occasionally reconfigured due to migration of a user equipment. Therefore, these factors contribute to packet losses detected by the TCP operating in a radio environment regardless of the congestion of the network. The packet losses, which are frequently called non-congestion packet losses, force the TCP to induce an unnecessary loss recovery process or RTO, thereby reducing a size of a congestion window to lower a data rate of a transmitting source.
FIG. 15 is a structural diagram of a relationship between an MIH function (MIHF) and other layers. The figure shows how the MIHF interacts with upper and lower layers in order to send and receive MIH function messages related to an MIHF user, including a TCP.
FIG. 16 is a structural diagram of a protocol. An MIH_TCP_SAP defines an interface between an MIHF and a TCP. An MIH_TCP_SAP is used to convey link layer status information to MIH users including the TCP. The MIH_TCP_SAP simply defines functions between the TCP and the MIHF. Furthermore, as long as an MIH_SERVICE_SAP has the same functionality as the MIH_TCP_SAP, then the MIH_SERVICE_SAP can replace the functions of the MIH_TCP_SAP described herein.